The reference doc was scoped to Phase 0+1 plus the suggest-gate. This
update extends it to cover everything shipping since:

- Phase 2 (merged): MSBuild passthrough via `--`, mode flags
  (--strict/--final/--quiet/--emit-threshold), the deterministic
  pre-emit policy table, and the suppress-to-error guardrail tool.
- Phase 3 (in flight on this branch): the IRulePattern infrastructure,
  RuleSymbolResolver / RuleRegistry, --disable-rule + --list-rules CLI
  surface, six authored rules (three Class-A induced + three Class-B
  vocabulary), the symbol-binding contract from §3.1a, and the
  per-rule perf bound test.
- Two critical correctness fixes uncovered during Phase 3 end-to-end
  smoke testing: CompilationLoader's ProjectReference resolution path
  and the suggest-gate carve-out for Tier-3 rules. Both get their own
  subsections in §3 explaining why unit tests passed while production
  silently no-op'd, since that failure mode generalises beyond this
  spec.
- The cross-agent mining drop (`claude-sonnet-4.6` × 525 runs) and the
  audit it produced. New subsection in §4 on comparing models to
  separate structural vocabulary-confusion signals from agent-specific
  idiosyncrasies; new subsection in §5 on what the second-agent corpus
  changed (B->A promotions, single-corpus deferrals, cross-syntactic-
  shape rule emergence).

§9 (Future improvements) tightened to what's actually left: remainder
of Phase 3 (more rules pending a third-agent corpus + Class-B catalog
expansion), Phase 4 (telemetry + learned ranker, blocked on Data
Checkpoint D), and a "what EC3 will tell us" subsection that frames
EC3 as a fresh measurement rather than an incremental delta on EC2.

Glossary gains: rule carve-out, pre-emit ranker, symbol-binding
contract, ProjectReference resolution, cross-agent audit, provenance.
TOC updated for the §8 rename ("in this PR" -> "so far").

Tone matches the existing doc: plain language first, then engineer
detail, then ML-practitioner detail. The same explanatory pattern
spec 038's design doc uses.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

PASS-with-caveats. Calc cleared the >=5% token-improvement bar
(-5.2% mean, -13.0% median); kanban regressed (+14.9% mean, +60.7%
median). The three Class-A rules added in this branch fired zero
times across all 10 variant runs - the EC3 delta did not exercise.
The calc improvement is plausibly driven by the CompilationLoader
+ gate carve-out fixes letting rules run at all, not by the new
rules.

Tool-call profile diff identifies the +3.2 turn delta on kanban:
variant agent does ~+1 skill load, +1 view, +1 apply_patch per run
vs base, consistent with a "verify-before-edit" loop triggered by
rule suggestions. Mechanism cited in handoff section 7.

Recommend: do not declare Phase 3 cleared on this batch alone.
Re-run with prompts that target GridSize/TextBlock patterns to
get Class-A rule exercise; investigate the kanban-base R1 outlier
(1.12M tokens, 3.4x median) before reading the kanban regression
as decisive.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…edit framing

Per-call inspection of variant kanban rg patterns and view paths
doesn't support the earlier "verify-before-edit" hypothesis: ~11/12 rg
calls probe drag/drop and modifier APIs unrelated to mur output; view
calls are mostly the agent re-reading its own in-progress workspace
files. The two rule-fired runs (r1=Theme, r4=Align) are middle-of-the-
pack on turns and tools, not the heaviest. The variant mean is dragged
up by r5 (20 turns, 27 tool calls, 889K tokens, zero rule fires) which
looks like a generic long-tail trajectory comparable to base R1.

Reframing: rule fires correlate with normal token usage when they
happen; mur check can't help on builds where the agent's mistakes
fall outside the rule set's coverage. The kanban-prompt -> rule-
coverage gap is the underlying issue, not rule-induced verification.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Single-character bug in tools/Templates/templates/WinUIApp-CSharp/
.template.config/template.json lines 5-6: the template's identity and
groupIdentity were "Micrsoft.UI.Reactor.CSharp" / "Micrsoft.UI.Reactor"
(missing the second 'o'). Checked into the repo since at least Phase 1.

How it surfaced. The eval harness runs `dotnet new install ... --force`
on every setup. Multiple installs accumulate duplicate entries in the
user's ~/.templateengine/dotnetcli/<sdk>/templatecache.json under the
misspelled identity. The duplicate-match condition makes
`dotnet new reactorapp` resolve more than one template for the
"reactorapp" short name, throwing "Sequence contains more than one
matching element" with exit code 70. The EC3 5x2 batch hit this 20/20
runs across both arms — the spec doc's earlier framing ("agent typo,
at least one variant kanban run, didn't block the build") was wrong on
three counts; corrected in this commit.

Why the existing integration test (CreateTemplateTests) didn't catch
the typo: it installs the template into a per-test ephemeral
--debug:custom-hive, where the misspelled identity is the only entry
and `dotnet new` resolves correctly. The bug only surfaces against the
user's real (accumulating) cache. The new test (described below) is
content validation, not install/run behavior — orthogonal coverage
that catches the typo regardless of cache state.

Test added: tests/Reactor.Tests/TemplateMetadataTests.cs. Four xUnit
[Fact]s that load template.json directly:
  - Identity_is_canonical_brand_namespace: exact-match assertion
    against "Microsoft.UI.Reactor.CSharp".
  - GroupIdentity_is_canonical_brand_namespace: exact-match against
    "Microsoft.UI.Reactor".
  - File_contains_no_brand_typos: substring sweep for "Micrsoft"
    anywhere in the file (belt-and-suspenders catch for future typos
    in any new symbol/description/etc.).
  - ShortName_resolves_to_reactorapp: anchors the public CLI command
    name documented in SKILL.md and the wordpuzzle smoke pattern.

Workstation cache drained + reinstalled: `dotnet new uninstall
Microsoft.UI.Reactor.ProjectTemplates` repeated until empty, then
`mur pack-local` repacked against the fixed template, then
`dotnet new install` reinstalled. ~/.templateengine cache now carries
exactly one canonical "Microsoft.UI.Reactor.CSharp" entry across both
SDK versions on disk (10.0.104, 10.0.203).

Existing tests unaffected: Reactor.Tests 7179 passing / 46 expected
skips (up from 7175, +4 from the new template-metadata tests).
CreateTemplateTests integration smoke (`dotnet new reactorapp` + build
+ run + UI Automation find) passes 2/2 with the corrected identity.

EC3 verdict implication: both arms hit the typo equally, so the
relative deltas (calc -5.2%, kanban +14.9%) are not biased *by this
bug*. Absolute costs are inflated on every run; the long-tail outliers
(variant r5 = 889K tokens, base r1 = 1.12M tokens) likely had their
trajectories pushed further by `dotnet-new` thrash. The PASS-with-
caveats verdict still stands directionally; a re-run with the typo
fixed could materially shift the numbers in either direction. Spec doc
updated to reflect this.

Two harness-side mitigations deferred to separate follow-ups (the
source typo is the load-bearing fix; without it the harness mitigations
would still leak):
  1. `dotnet new uninstall Microsoft.UI.Reactor.ProjectTemplates`
     before `dotnet new install --force` in eval setup, so future
     typo-equivalent bugs can't accumulate.
  2. Propagate inner-command exit codes into the PowerShell tool
     wrapper's `success` field so `failedToolCalls` stops lying about
     dotnet-new failures.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

EC3-post-typo-fix smoke trace analysis identified two reads following
the scaffold: `view App.cs` (essential — the file the agent is about
to apply_patch) and `view <project>.csproj` (defensive — the agent
checking that the scaffold produced a sane csproj). The .csproj read
is informational at best: the scaffold's stdout already showed the
file listing plus "Restore succeeded.", and a calc/kanban-shaped task
never modifies the .csproj.

Across the prior 10 variant runs, calc averaged 2.2 views/run and
kanban averaged 2.2 (r5's 4 reads pulling the kanban mean up). Two
views post-scaffold is the modal pattern, so a one-line skill note
landing on the defensive read should compress noticeably.

Added the same one-line note in two places so both skill consumers see
it:
- plugins/reactor/skills/reactor-getting-started/SKILL.md right after
  the canonical .csproj block (line ~102, next to the
  WindowsPackageType / UseWinUI MUST rules).
- SKILL.md (top-level, packed into the nupkg) right after the matching
  csproj block in the Project Setup section.

The wording explicitly carves out App.cs as still-necessary so the
note doesn't suppress useful reads. Estimated savings: one view + a
few hundred tokens per scaffold step. Small per-run, real across the
batch since every eval scaffolds.

Repacked Microsoft.UI.Reactor.0.0.0-local.nupkg so the bundled
agentkit/SKILL.md carries the update.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…anti-probe + mur check pointer

Three related changes addressing the post-scaffold agent-confusion pattern
the EC3-post-typo-fix trace analysis identified:

1. tools/Templates/templates/WinUIApp-CSharp/Company.ReactorApp1.csproj
   removes <ImplicitUsings>enable</ImplicitUsings> and the three <Using
   Include="..."> items. Reactor's namespaces are now explicitly
   `using`-imported at the top of App.cs:
       using Microsoft.UI.Reactor;
       using Microsoft.UI.Reactor.Core;
       using static Microsoft.UI.Reactor.Factories;
   Why: with implicit usings on, the source file looks like it's missing
   namespace context — `VStack`, `Heading`, `Component` appear unqualified
   without a visible `using`, which confuses agents reasoning about where
   symbols come from. The agent has to read the csproj to find the global
   Using items, then mentally merge them into App.cs's namespace scope.
   Explicit usings make App.cs self-contained: every symbol's source is
   one of the three using directives at the top of the file. The skill
   text now says "App.cs has its own using directives at the top, which is
   the only place you add new namespaces" — which is true after this
   change.

2. SKILL.md + plugins/reactor/skills/reactor-getting-started/SKILL.md
   expand the existing "trust the scaffolded .csproj" note into an
   anti-probe paragraph that enumerates the exact post-scaffold file
   list: "the workspace contains exactly two source files: App.cs (entry
   point + initial component) and <Name>.csproj. There is no Program.cs
   and no GlobalUsings.cs — modify App.cs in place."
   Why: the eval orchestrator's trace analysis identified a recurring
   "agent probes for files that don't exist" pattern (sometimes asking
   for Program.cs, sometimes inspecting obj/GlobalUsings.g.cs). Pinning
   the file list in the skill is a one-paragraph fix.

3. Same two SKILL.md files add a 1-paragraph mur check pointer alongside
   the anti-probe note: "Verify your edits with mur check before
   declaring done... For anything more involved than the build/fix loop —
   strict-mode failures, custom diagnostic gating, MSBuild passthrough
   flags — load the reactor-build-and-check skill."
   Why: the deeper reactor-build-and-check skill is a heavy load (full
   --strict / --final / --quiet / --emit-threshold / --suppress-error
   surface plus the iter/final framing). Most agent runs just need the
   basic loop. Promoting mur check into getting-started with a one-liner
   for the basic case lets the agent stay in the lighter skill until
   they actually hit advanced behavior.

Verified: dotnet new reactorapp -n X builds clean in both the top-level-
program default and the --use-program-main true variant. Existing
CreateTemplateTests integration smoke (2/2) and TemplateMetadataTests
unit tests (4/4) pass. mur pack-local refreshes both nupkgs against the
new template + skill content.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The prior commit (94d563f) added three usings to App.cs (Microsoft.UI.
Reactor, .Core, static Factories) so the source is self-contained after
dropping <ImplicitUsings>. The skill's "Required imports" section
documents the full *canonical* set as five-plus-one — adding
Microsoft.UI.Reactor.Layout, Microsoft.UI.Xaml, and
Microsoft.UI.Xaml.Controls to the minimum three. The template and the
skill now diverged: the agent reading App.cs would see three usings
but the skill text says the canonical set is six.

Sync the template to the skill: App.cs now ships all five-plus-one
using directives, with the same `// FlexDirection, FlexJustify, ...`
inline comments the skill uses for each non-obvious namespace. The
starter App.cs still only uses three of them (Reactor, Core, static
Factories); the other three are there because the agent will reach
for them within the first ~5 turns of any real app (alignment enums,
InfoBarSeverity, FlexDirection).

Updated the SKILL.md anti-probe paragraph in both copies to point at
`using System.Linq;` as the example of "when you add a new namespace,
add it to App.cs's using block" — System.Linq is a real common add and
isn't in the canonical six, so the example stays accurate. The top-
level SKILL.md also explicitly names the canonical set so readers can
cross-reference without flipping to the imports section.

Verified: dotnet new reactorapp -n X builds clean in the default
variant. CreateTemplateTests integration smoke 2/2 and
TemplateMetadataTests 4/4 pass against the expanded usings.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

With ImplicitUsings disabled (template commit 94d563f) the agent doesn't
get System auto-imported. Common BCL surface — Action, Func, EventArgs,
DateTime, Math, TimeSpan, Random — all live there, and they show up
within the first few turns of any non-trivial app (event handlers,
timers, randomization, formatting). Adding `using System;` to the
template's App.cs eliminates the "Action does not exist in the current
context" miss that's otherwise the first thing the agent hits when
they author an event handler.

Synced the canonical set in three places so they stay coherent:
- tools/Templates/templates/WinUIApp-CSharp/App.cs (scaffold output)
- plugins/reactor/skills/reactor-getting-started/SKILL.md "Required
  imports" code block
- SKILL.md anti-probe note's parenthetical canonical-set list

Verified: scaffolded App.cs ships `using System;` at the top of the
canonical seven-line using block; default-variant build clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Five surgical removals identified by the analysis pass:

A. "Minimal app — single file" block (36 lines → 5). The single-file
   `dotnet run App.cs` flow is a side path now that `dotnet new
   reactorapp` is the primary entry; the canonical-shape teaching
   moved into the scaffolded App.cs. Kept a 1-paragraph pointer to
   reactor-build-and-check's single-file-scripts section for the
   demo case.

B. Standalone `.csproj` xml block (17 lines dropped). The xml taught
   the agent how to write a csproj from scratch — but the agent
   doesn't author one. `dotnet new reactorapp` produces it. Kept the
   "when to use a .csproj" framing + the WindowsPackageType /
   UseWinUI MUST-rules + the recently-added anti-probe + mur check
   paragraphs.

C. "Mode detection — selfhost vs. NuGet consumer" section (29 lines
   → 2). The top-level SKILL.md already owns selfhost/consumer
   bootstrap; re-explaining it here was a second copy. The new
   one-paragraph "Bootstrap" section breadcrumb-points readers to
   SKILL.md and keeps the load-bearing `mur pack-local` recovery
   tip inline.

D. "App entry point" section (13 lines → 0). The ReactorApp.Run<App>
   form is already in the scaffolded App.cs. The unique content was
   the inline-render-function form `ReactorApp.Run("T", ctx => ...)`
   — embedded that as a one-line addendum to §Components instead of
   carrying a whole section for it.

E. "Where the skill content comes from" package-cache directory tree
   (6 lines dropped). The literal `%USERPROFILE%\.nuget\...` block
   was reference material an agent can `find` on demand. Kept the
   plugin-channel framing + the api-index pointer + the "read once,
   cache in working memory" tip.

What's preserved unchanged:
- The React→Reactor table (highest-value block in the file)
- Components / Hooks / Common factories / Theme tokens / Critical
  gotchas (load-bearing reference content)
- The recent anti-probe + mur check paragraphs
- The trimmed sections still carry their breadcrumb pointers so
  agents looking for the removed content find their way to the
  right skill (reactor-build-and-check, top-level SKILL.md, etc.)

Tier 2 (move drag-and-drop to reactor-input, trim Context, drop
duplicate List/UseReducer callout) and Tier 3 (move ContentDialog +
Flyout to reactor-recipes) are follow-up considerations, not applied
in this commit — they want eval validation before landing.

Repacked Microsoft.UI.Reactor.0.0.0-local.nupkg so the bundled
agentkit/plugins/reactor/skills/reactor-getting-started/SKILL.md
carries the trimmed file (verified: nupkg copy is 415 lines, matches).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Append the EC3-final results subsection to the implementation tasks
doc; mark EC3-original as superseded (preserved as the historical
record of the typo-contaminated batch and the PASS-with-caveats
reasoning that drove the watch-item triage work).

EC3-final headline numbers (5×N landed 2026-05-12 on
eval/spec-038-ec3-2026-05-11 @ 053afe9):
  calc:   tokens −33.7% mean / −37.1% median, cost −25.6%,
          turns −2.2, CV 28.4%, first-build 5/5
  kanban: tokens −21.2% mean (median +31.7% is the
          distribution-tightening artifact, not a regression —
          base CV 74% bimodal vs variant CV 19.5% no-fat-tail),
          cost −25.7%, turns 0, first-build 5/5

The 4× kanban CV improvement is the load-bearing finding — second
batch in a row (after EC1-RR) where the predictability-as-a-feature
signal shows up, first batch where calc also tightens.

All four EC3 pass criteria cleared. Spec §12's "~−$0.70 per run"
prediction comfortably exceeded on both arms ($0.66 calc, $1.08
kanban). Spec EC3 row's "~−2 turns" prediction hits calc exactly.

One unresolved footnote: per-rule firing counts weren't broken out
in this batch. EC3-original was 0/10 on the three new Class-A rules;
this clean PASS may be carried entirely by the structural fixes +
template + skill changes with the three new rules still inert. The
verdict supersedes EC3-original regardless (rules are correct in
isolation, pass bars #1-#4 + #6, don't actively harm when silent),
but the targeted-prompt batch at C:\temp\mur-targeted-prompt-spec.md
remains the load-bearing follow-up for getting empirical token-
impact numbers on those three rules specifically.

Watch-items carried into V1 / Phase 4 review:
- Class-A rule exercise via targeted-prompt batch
- §11 risk-row guardrail retrofit (post-run mur check --final audit)
- Tier-2 SKILL.md trims (now empirically de-risked)
- rule_fired trace event addition

Verdict: PASS, clean. Phase 3 V1 cleared to ship. PR #250 updated
with the same verdict in its body.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>